Interesting machine, I must say.
Regarding the "PID" correction of the master/slave azimuth axis: I take it that your drive system allows some slippage, like maybe it is a friction drive not a circular rack. So you need to correct for relative displacement between the two driving sides. You can only perform the correction at the quadrant points where there is some sort of index pulse. Is this roughly correct?
If so, then one way I would try would be to have a dedicated thread running in the kflop, which looks for the index pulses encountered by master and slave (M,S). Initially, your slave gain would be 1 (i.e. exactly 1:1 ratio of M to S). Since you said it basically moves in one direction, then you should be able to assume that there has been roughly 90 degrees of motion between each index pulse received. When 2 index pulses have been seen from both M and S, then you can compute whether S is running fast or slow w.r.t. M. Using that data, you re-compute the slave gain to compensate.
This is made a bit tricky because:
- you need to catch up ("anti racking") over some interval, then revert to the theoretical adjusted gain thereafter (unless you can tolerate a discontinuity where you pause and move the slave axis to 180 deg opposite the master). Maybe it would be sufficient to adjust the slave gain by an additional amount depending on the angular offset, which will make it catch up over a longer period, but should still converge on the correct gain and offset, like a PLL.
- When you change the slave gain, I am not sure whether the kflop will "jump" the slave, or whether it adjusts the ratio with no positional discontinuity. Tom would have to answer this.
- You probably want the master axis to maintain an absolute reference w.r.t one of the index pulses, so you will want to adjust its output gain as well.
Regarding the "streaming" (dynamic generation) of g-code: as Tom noted, it's really file oriented, because it sometimes needs to seek around in the file to locate subroutines etc. Maybe g-code is not a very good fit for your application because of its extremely limited decision/feedback capability. You can fake it to some extent by having the kflop issue MDI commands to the PC. I guess it depends on what sensors/events drive the dynamics, and whether the sensors are available to the kflop or the PC. You seem to have more of a robot type machine than a "dumb" CNC device.
Of all the great things about the kflop, one that stands out is the ability to move away from the g-code model, and move more towards a robotics model i.e. more feedback. For example, on our machine we now have dynamic force feedback, simply by monitoring the integrator windup and following error on each axis.
Regards,
SJH
